NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/468

Text File | 1996-08-06 | 5.4 KB | 125 lines

Path: mail2news.demon.co.uk!pires.demon.co.uk
From: rpp <[e-mail]>
Newsgroups: comp.std.c
Subject: Re: Is a diagnostic required?
Date: Wed, 28 Feb 1996 16:19:39 GMT
Organization: Pi Technology Ltd
Distribution: world
Message-ID: <[e-mail]>
References: <[e-mail]> <danpop.824999740@rscernix>
Reply-To: [e-mail]
X-NNTP-Posting-Host: pires.demon.co.uk
X-Broken-Date: Wednesday, Feb 28, 1996 16.19.39 GMT
X-Newsreader: Newswin Alpha 0.6
X-Mail2News-Path: disperse.demon.co.uk!post.demon.co.uk!pires.demon.co.uk

In article: <[e-mail]>  [e-mail] (Mark Brader) writes:
>
> Dan Pop ([e-mail]) writes:
> > Does the following code require a diagnostic?
> >
> >     foo() { }
> >     main() { foo(3); } >
> > I was always convinced that there is no difference between foo() and
> > foo(void) in the _definition_ of the function foo ... Yet, all the
> > compilers I tried accepted this code without complaint and complained
> > when 'void' was introduced in the definition of foo.
>
> The language of the standard is fuzzy here, but I believe that it is
> clearly intended for the diagnostic to be mandatory when the "void" is
> present, and optional otherwise (the behavior being undefined).
>
> An excerpt from the Constraints of section 6.3.2.2/3.3.2.2 (emphasis added):
>
> #  If the expression that denotes the called function has a type that
> #  INCLUDES a prototype, the number of arguments shall agree with the
> #  number of parameters.
>
> As this is a Constraint, a violation requires a diagnostic.  But from the
> Semantics of the same section (emphasis added):
>
> #  If the expression that denotes the called function has a type that
> #  DOES NOT include a prototype ...  If the number of arguments does
> #  not agree with the number of parameters, the behavior is undefined.
>
> Thus no diagnostic is required if this is the only violation.  I must
> say it's rather disgusting that none of the compilers Dan tried was smart
> and helpful enough to produce the diagnostic anyway -- it would after
> all be easy enough for them to do so in this case.  (Cancel that remark
> if they were all compilers intended to be used with lint for checking.)
Don't be too unfair to the compiler writers - they're trying to write
compilers that accept K&R C as well as ISO C. You may not think this is a
good idea, but there's vast amounts of legacy code with K&R header
files out there.... The authors of the standard tried to make it
compatible with "current practice" (ie K&R) as far as possible: that is
why the declaration of foo() with no parameters is allowed at all.
>
> Now, "prototype" is defined in 6.1.2.1/3.1.2.1:
>
> #  A "function prototype" is a declaration of a function that declares
> #  the types of its parameters.
>
> And in case there was any doubt, both 6.5/3.5 and 6.7.1/3.7.1 make it
> clear that a definition is a kind of declaration.  I won't bother to
> quote them here.
>
>
> These passages are sloppy for the following reasons:
>
> 1. "Function prototype" is defined, but the term used elsewhere in the
>    standard is just "prototype".
>
> 2. It is defined as a syntactic construct, not something that might be
>    "included" in a type.
>
> 3. If a function has no parameters, it is not possible to distinguish
>    whether they are declared or not.
>
> 4. The old-style function definition
>
>     void fu (x,y) short x,y; { }
>
>    is a declaration that declares the types of the function's parameters,
>    but if this was deemed to be a prototype, existing code would be broken.
>
>    The way to resolve both points 3 and 4 is to relate the term "prototype"
>    more directly to the new-style syntax, which it is obviously intended
>    to denote.  In section 6.5.4.3/3.5.4.3, where function declarators and
>    their semantics are actually defined, the term is avoided altogether and
>    "parameter type list" is used instead.  "Prototype" probably should have
>    been defined in these terms.  Note that void is a type, so foo(void)
>    would be a valid function declarator with a prototype, while foo()
>    would unambiguously not have a prototype.  There is no syntactic
>    ambiguity since a parameter type list is not allowed to be empty.
>
> 5. The punctuation of the quoted passage from 6.3.2.2/3.3.2.2 Semantics
>    is ambiguous: it isn't clear whether the first If-clause quoted is
>    meant to govern the second one, which is in a different sentence.
>    More precisely, the punctuation suggests that it does not, but in
>    other places in the standard similarly punctuated, it would.  In
>    this case, however, material later in the paragraph suggests that
>    the last-quoted If-clause is not meant to be within the scope of the
>    other one.
>
>    Fortunately, this parsing ambiguity makes no difference in this case;
>    the overall effect is the same with either parsing, no matter whether
>    a prototype is used or not.
>
> If you take the intended readings as being what I said, then you end up
> with the conclusion I gave above.  If not, you probably don't.
> --
> Mark Brader, [e-mail]       "I'm not a lawyer, but I'm pedantic and
> SoftQuad Inc., Toronto         that's just as good."      -- D Gary Grady
>
> My text in this article is in the public domain.
>
>

--
Richard P. Parkins, M. A.     [e-mail]
Pi Technology Ltd.            [phone]
Opinions expressed were mine at the time of posting,
otherwise all possible disclaimers apply.